Database systems, such as SQL servers, contain vast amounts of information generated and used by application programs. For example, many organizations, such as companies and nonprofit organizations, use application programs to manage financial records, inventories, and transaction histories using database systems. These application programs include point-of-sale programs, accounting programs, customer relation management programs, enterprise resource management programs, security programs, and so on. To support these application programs, an organization may create a database that has hundreds of tables and many fields in each table. For example, a database may include an employee table, a customer table, a product table, an invoice table, an accounts receivable table, a quality assurance table, a maintenance table, an inventory table, and so on. An employee table may include a row for each employee of the organization and include an employee identifier field, an employee address field, an employee start date field, and so on. The employee identifier field may uniquely identify the employee within the organization.
Because of the importance of the information stored in the database of the organization, database systems typically provide mechanisms to back up and restore the databases managed by that system. A backup mechanism may create a complete copy of the database, and the restore mechanism may overwrite the database with the copy. A database system may also use roll forward and roll backward technology to restore a database. Such a database system may log all transactions and use those transactions to restore a database to a particular state by starting at a known prior state and applying transactions that occurred after that state (i.e., roll forward) or by starting at the current state and un-applying transactions that occurred before the current state (i.e., roll backward).
A database system may also provide a snapshot mechanism that allows the state of a database at a snapshot time to be preserved in a “snapshot.” Once a snapshot is created, subsequent changes to the database are not reflected in the snapshot. For example, a snapshot of a database may be made at the end of each quarter and quarterly reports can be run against that snapshot even though the database may continue to be modified. Instead of making a complete copy of the database, a snapshot mechanism may copy only those portions of the database as they changed after the snapshot is created. The snapshot technology may monitor for changes in the database and create a copy of those portions that are to be changed. Thus, the state of the database at the time of the snapshot includes the copied portions and the remaining portions of the database that have not been changed.
Each database system may consider its backup and restore technology and snapshot technology to be proprietary. As a result, the format and content of information stored by a database system to support these technologies may not be readily available outside the organization that developed the database system.
During the development of application programs that use a database, the developer typically needs to assess differences in the database resulting from a new version of the application program. To identify the differences, the developer may first perform an old procedure of an old version of the application program on a test database that is in a known state and then perform a new procedure of a new version of the application program on the test database that is in the same known state. The developer can then identify any differences and determine whether they indicate a problem in the programming of the new procedure.
Because an application program may have hundreds or thousands of procedures that need to be tested, the testing process can be very time-consuming. One aspect of the testing that can be particularly time-consuming is the returning of the test database to the known state after each procedure is performed. Because each procedure may modify the test database, subsequent procedures cannot practically be tested until the test database is returned to the known state. A developer may return the test database to the known state by saving a copy of the test database in the known state (e.g., backing up) and then recopying the test database (e.g., restoring) after each procedure is performed. Because a test database can be very large, it may, however, be impractical for the developer to maintain a copy of the test database in the known state, and it can be very time-consuming to recopy the database. A developer may also return the test database to the known state by using the restore technology provided by the database system. The restoring of a database to the known state can itself, however, be very time-consuming.